The Twofish Encryption Algorithm: A 128-Bit Block Cipher The Twofish Encryption Algorithm: A 128-Bit Block Cipher
by Bruce Schneier ; John Kelsey ; Doug Whiting ; David Wagner ; Chris Hall ; Niels Ferguson
Wiley Computer Publishing, John Wiley & Sons, Inc.
ISBN: 0471353817   Pub Date: 03/01/99
  

Previous Table of Contents Next


Chapter 10
Using Twofish

10.1 Chaining Modes

All standard block-cipher chaining modes work with Twofish: CBC, CFB, OFB, counter [NBS80]. We axe aware of no problems with using Twofish with any commonly used chaining mode. (See [Sch961 for a detailed comparison of the various modes of operation.) A cryptanalyst considering OFB-, CFB-, or CBC-mode encryption with Twofish may collapse the pre- and post-whitening of key material into a single XOR, but he does not appear to benefit much from this.

10.2 One-Way Hash Rinctions

It is not hard to build a one-way hash function out of Twofish [Win84]. We suggest the following construction, taken from [Pre93]:

Hi = MiEHi-1 (Mi)

This mode seems to be somewhat preferable to Davies-Meyer, because it gives the cryptanalyst less control over the value entering the key port and thus may provide more robust protection in case there are any related-key attacks on Twofish.

We believe that Twofish, with its strong key schedule, can be used securely in any of these formats. Note, however, that the key schedule has been analyzed mainly for related-key attacks, not for the class of chosen-key attack that hash functions must resist. Additionally, the 128-bit block size makes straightforward use of this construction useful only when collision-finding attacks can be expected to be unable to try 264 trial hashes to find a collision.

As keys that are non-standaxd sizes have equivalent keys that are longer, any use of Twofish in a hashing construction must ensure that only a single key length is used. We recommend using 128-bit keys for hashing constructions.

10.3 Message Authentication Codes

Twofish can be easily used to build a very strong message authentication code using the CBC-MAC construction [BKR94]. In fact, [BKR94] gives formal proofs of security for the CBC-MAC approach, assuming that the underlying cipher is secure. We feel that this makes Twofish-CBC-MAC a very strong candidate for use in message authentication applications.

Alternatives include using Twofish as a hash function, and then constructing a MAC out of the hash function [BCK96].

10.4 Pseudorandom Number Generators

Twofish can also be used as a primitive in a pseudorandom number generator suitable for generating session keys, public-key parameters, protocol nonces, and so on [Plu94, KSWH98a, Gut98, KSWH98c].

10.5 Larger Keys

Even though it would be straightforward to extend the Twofish key schedule scheme to larger key sizes, there is currently no definition of Twofish for key lengths greater than 256 bits. We urge caution in trying to extend key lengths; our experience with Twofish has taught us that extending the key length can have important security implications.

10.6 Additional Block Sizes

There is no definition of Twofish for block lengths other than 128 bits. While it may be theoretically possible to extend the construction to larger block sizes, we have not evaluated these constructions at all. We urge caution in trying to extend the block size; many of the constructions we use may not scale well to 256 bits, 512 bits, or larger blocks.

10.7 More or Fewer Rounds

Twofish is defined to have 16 rounds. We designed the key schedule to allow natural extensions to more or fewer rounds if and when required. We strongly advise against reducing the number of rounds. We believe it is safe to increase the number of rounds, although we see no need to do so. Note that the key schedule cannot support more than 124 rounds, as the 8-bit input counter to the key schedule S-boxes overflows.

Algorithm Key Length Width (bits) Rounds Cycles Clocks/ Byte
Twofish variable 128 16 8 16.1
Blowfish variable 64 16 8 19.8
Square 128 128 8 8 20.3
RC5-32/16 variable 64 32 16 24.8
CAST-128 128 64 16 8 29.5
DES 56 64 16 8 43
Serpent 128,192, 256 128 32 32 45
SAFER (S)K-128 128 64 8 8 52
FEAL-32 64, 128 64 32 16 65
IDEA 128 64 8 8 74
Triple-DES 112 64 48 24 116
Table 10.1. Performance of Different Block Ciphers (on a Pentium)

More and more recent ciphers are being defined with a variable number of rounds; e.g., SAFER-K64 [Mas94], RC5 [Riv95], and SPEED [Zhe97]. This means that it is impossible to categorically state that a given cipher construction is insecure: there might always be a number of rounds n for which the cipher is still secure. However, while this might theoretically be true, this is not a useful engineering definition of “secure.” After all, the user of the cipher actually has to choose how many rounds to use. In a performance-driven model, it is useful to compare ciphers of equal speed, and compare their security, or compare ciphers of equal security and compare their speeds. For example, FEAL-32 is secure against both differential and linear attacks. Its speed is 65 clock cycles per byte of encryption, which makes it less desirable than faster, also secure, alternatives. As speed is relatively easy to measure and quantify, the simplest way of comparing ciphers in a performance-driven model is to choose the number of rounds in such a way as to make the two ciphers equally fast. The hard question of “which cipher is more secure” then remains, but at least that is a clearly defined problem.

With that in mind, Table 10.1 gives performance metrics for block and stream ciphers on the Pentium processor.1 Similar comparisons are being done for the AES candidates [SKW+99a], and will presumably be one of the criteria in the selection process.


1These metrics are based on theoretical analyses of the algorithms and actual hand-tooled assembly-language implementations [SW97, PRB98a, PRB98b].


Previous Table of Contents Next